Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Memory

Memory is the most important area you can tune in the server operating system. By reserving a sufficient amount of memory for the proper size SGA for your system, you will see a good balance between CPU and I/O. If your SGA is too small, you may see idle CPU cycles when Oracle is doing nothing but waiting for I/Os to complete. If this occurs, your machine has become I/O bound. Frequently, all you need is a larger SGA to achieve the right balance.

In NetWare and Windows NT, the memory used for Oracle is the same as any other memory used in the system. In the UNIX operating system, you must reserve shared memory for the SGA. The shared memory area is a special type of memory that allows multiple processes to access the same memory.

In some UNIX implementations, you may be able to take advantage of Page Size Extension (PSE) memory. PSE memory uses a much larger page size and thus reduces memory page lookup thrashing in the OS. Be careful of the restrictions associated with PSE memory; the amount of PSE memory you allocate is frequently reserved at boot time and is not available for other uses in the system, even if it is not used.

I/O

I/O is another important area you must sometimes tune in the server OS. In some operating systems, there is nothing to tune; in others, you can change parameters to improve I/O performance. Depending on the operating system, you may have to change the database block size to take advantage of the OS block size.

Of course, the best way to improve I/O performance is by carefully distributing data files to take advantage of the available I/O bandwidth. By separating sequential and random I/Os, you can take advantage of the available disk throughput, as described in Chapter 13, “System Processors,” and Chapter 14, “Advanced Disk I/O Concepts.”

If you use OS striping for fault tolerance or performance, you may have to tune several parameters within the disk striping or file system subsystems. This requirement varies depending on the operating system and striping method.

The way in which operating systems do I/O is also very important. Although the operating systems examined in Chapter 12, “Operating System-Specific Tuning,” have various methods of handling I/Os, many concepts are the same. Whether you use Direct FS under Windows NT or NetWare, raw UNIX synchronous I/O, or raw devices, the way Oracle does I/O must be handled the same. And regardless of the operating system you use, the concept of Asynchronous I/O is always the same.

I/O Methods

In order for Oracle to manage its cache (the SGA) and guarantee data recovery in the event of a system failure, OS disk caching must be turned off. If the Oracle processes believe that data has been written to disk, but in fact the data was in the OS disk cache at the time of failure, Oracle cannot recover that data. To avoid this, Oracle uses disk I/O interfaces that do not use the OS disk cache. The following interfaces are used:

Direct FS With Novell NetWare and Microsoft Windows NT, the Direct FS interface is used. This interface uses the standard file system but does not cache the data in the OS disk cache.
Synchronous I/O The UNIX equivalent of Direct FS. Disk I/Os are not cached. This interface is not related to the concept of Asynchronous I/O.
Raw devices Raw devices are available under UNIX and Windows NT; they provide an interface to the I/O subsystem that avoids the file system. This interface is faster because it avoids unnecessary OS overhead.
Asynchronous I/O With Asynchronous I/O, the process performing the I/O (usually the DBWR process) submits a list of I/Os to the OS and continues processing. When the I/Os are done, the process receives an interrupt and can go retrieve the data.

To have more insight into how the system operates, you should look a little deeper into how Oracle does I/O: Oracle has a sophisticated cache management system. Using the database block buffers and the shared pool, much of the frequently used data can be stored in memory for quick retrieval. Working closely with this cache management system is the Oracle redo log. With the cache and the redo log, Oracle has created both a high performing and robust database management system.

To keep the data files and redo log synchronized, Oracle must perform I/Os in a specific way. Oracle must make sure that when the RDBMS believes data has been written to the data files, that data is there. Oracle ensures this by using the operating system I/O interface. In NetWare or Windows NT, this interface is called the Direct FS interface. In UNIX, this interface is the synchronous I/O interface. In UNIX or Windows NT, you can also use raw disk devices.

Direct or Synchronous I/O

With direct or synchronous I/O, the process requesting the I/O must block on the physical I/O. To block on the I/O means that the process goes to sleep waiting for the I/O to return. With normal I/O, the process blocks on the I/O, but the I/O returns completed when the data has been written into the OS disk cache. With synchronous I/O, the process blocks on the I/O, but the I/O does not return until the data has been physically written to the disk. This method of I/O ensures data integrity.

Synchronous I/Os are so important because of the way Oracle does data recovery. Remember the concept of the checkpoint. At one point in time, Oracle writes out all the dirty buffers in the SGA. All the data that has been changed up to the time at which the checkpoint started is written out. Once the checkpoint has completed, the data files are updated to indicate that the data file is current up to the last checkpoint. Once Oracle has written data to the disk, no recovery is performed on that data in the event of a system failure. If Oracle thought it had written this data to disk, but in fact the data been written only to the OS disk cache, when a failure occurs, this data cannot be recovered and the database will have incorrect data in it. From the standpoint of the DBWR process, the data has been written to disk. Data integrity cannot be maintained without Direct FS or synchronous I/Os

However, by using synchronous or direct I/O to ensure that all data has really been written to disk, there is no integrity problem. Only by using synchronous or direct I/O can data integrity be ensured. Every operating system offers some sort of direct or synchronous I/O.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.